Conversation
Logic.py
Outdated
| def maktar_photo_booth_rule(state: CollectionState, player: int) -> bool: | ||
| options = get_options(state, player) | ||
|
|
||
| if (options.first_person_mode_glitch_in_logic >= FIRST_PERSON_MEDIUM | ||
| and options.charge_boots_in_logic): | ||
| return (can_electrolyze(state, player) | ||
| or can_heli(state, player) | ||
| or can_charge(state, player)) | ||
|
|
||
| if options.first_person_mode_glitch_in_logic >= FIRST_PERSON_MEDIUM: | ||
| return (can_electrolyze(state, player) | ||
| or can_heli(state, player)) | ||
|
|
||
| if options.charge_boots_in_logic: | ||
| return (can_electrolyze(state, player) | ||
| or can_charge(state, player)) | ||
|
|
||
| return can_electrolyze(state, player) |
There was a problem hiding this comment.
Taking this function as an example, I think it would be cleaner to do somthing more like this:
def maktar_photo_booth_rule(state: CollectionState, player: int) -> bool:
if can_electrolyze(state, player):
return True
options = get_options(state, player)
if options.first_person_mode_glitch_in_logic >= FIRST_PERSON_MEDIUM:
if can_heli(state, player):
return True
if options.charge_boots_in_logic:
if can_charge(state, player):
return True
return FalsePutting the vanilla (usually most strict) logic at the top of the function and early escaping if true. From there, we can catch the less strict logic that is enabled, and if uncaught return False at the end. To me, this seems like a good strategy for handling these rule functions.
|
Since we're starting to include multiple glitches, I think it's a good time to bring up my thoughts on how these options will be displayed to users. Having each trick/glitch enableable piecemeal in the options (like OOT) is too much in my opinion. I would rather have global glitch logic difficulty with options Easy/Medium/Hard. This would be separate from any eventual combat logic difficulty which would also likely be split into Easy/Medium/Hard. |
|
On other APWorlds I've worked on, using one global logic difficulty option helped a lot reducing logic complexity. The reasoning behind it was the following, with examples that would apply for RaC2:
This video is a pretty good showcase of most existing movement tech (and a bit more) |
|
I understand how complex having so many options for each glitch can become. But as long as things are clearly defined, I think we can go for that route of a single option for everything. I haven't researched movement tech yet, so I like that linked video. |
|
I refactored the logic according to your suggestion of having a global option with multiple difficulties. I still have to look at the movement tech. |
|
|
||
| if options.first_person_mode_glitch_in_logic >= FIRST_PERSON_EASY: | ||
| if options.glitch_logic_difficulty >= GLITCH_LOGIC_HARD: | ||
| return True |
There was a problem hiding this comment.
I see going from FIRST_PERSON_EASY to GLITCH_LOGIC_HARD in a few places. Is this intended?
There was a problem hiding this comment.
I looked at Dinopony's examples and thought most FPM should go in the same difficulty as Charge Boots tech, as I consider it some kind of glitch and not a simple movement tech.
There was a problem hiding this comment.
I've had some more time to think about this and it brings up some major problems with considering FPM in logic. It basically undercuts other more interesting tricks and glitches that we want to add into logic later. There are going to be many places where a location could be reached with some precise jump are movement tech but with FPM could done very easily making the overall glitch logic easy.
Obviously I've changed my mind on this so I'm not necessarily set in stone but here's what I think should be done.
- Add FPM back as an option
- Ignore FPM in glitch logic and treat it like a fun bonus option.
I think without other glitch logic this feels like removing a feature but as glitch logic gets more fleshed out, it will become more clear that FPM makes things less interesting. It is a least clear to me now that if FPM is in logic at all, it should be completely separate like you had it originally. I'm just not convinced that having special glitch logic just for FPM is worth the complexity, especially once other glitch logic gets implemented.
There's definitely more room for discussion on this. Just wanted to get my thoughts out there.
There was a problem hiding this comment.
I agree on FPM being broken and making so much of the game trivial.
I like the idea of it being an option, but depending on the complexity increase of having it separated, maybe we could remove it altogether.
I think it might be as simple as adding something like the following in most checks:
if options.fpm and options.glitch_logic_difficulty >= GLITCH_LOGIC_MEDIUM:
return True
|
Looking pretty good so far.
Whatever works best for your workflow. |
|
In that case, since I didn't know of all Charge Boots tech, I think I will add more to the PR, so that the feature makes much more sense than having only some FPM and some Charge Boots. |
|
Since i noticed this in updating the tracker for the previous change that only had FPM glitches in logic: with the locations on Tabora and Aranos each having gotten their own set of access_rules for logic, the special access_rules in Regions.py could potentially be removed as the base logic is included in the functions in Logic.py. Not sure if the overlap can cause any unwanted/unintended logic to happen. Access via region: Example Plumber: Would Plumber require the Infiltrator or not? region says yes, location itself says no |
# Conflicts: # Logic.py # Simplified Ratchet & Clank 2.yaml
Pecomare
force-pushed
the
add-charge-boots-in-logic
branch
from
7bd8e25 to
226d7f4
Compare
4 participants
This PR adds an option to place the Charge Boots in the logic.
For those unaware of the exploit: when the charge of the boots ends, there is a forward momentum. If you strike with the wrench right afterwards (which can be done in the air and is performed as if you were on the ground), you can momentarily keep that momentum with a side-jump or a dash with the Heli-pack. This speed gain allows you to gain access to some platforms without having the intended item (e.g. Maktar Jamming Array being reachable without the Tractor Beam)
I noticed I made some mistakes with some FPM logic so I fixed them in the PR.